home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 12223 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.4 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Hiding a password
  5. Date: 29 Mar 1996 16:13:45 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4jhnap$56b@solutions.solon.com>
  8. References: <4jc0gu$crg@fnord.dfw.net>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <4jc0gu$crg@fnord.dfw.net>,
  12. Azazel Diabolus            (aka Fetelgeuse) <ftlgeuse@dfw.dfw.net> wrote:
  13. >OK, Tanmoy, there is no need to be such a smart-ass. The code I posted was
  14. >a mere "snippet" to give the original poster and idea of the "theory" of
  15. >my suggestion. I openly admitted that the code verbatim probably would not
  16. >do the trick which is why I explained what it was doing. It is not up to me
  17. >to ensure that each reader knows how to properly prototype his/her functions,
  18. >or knows which header files to include for a given function (i.e. getch())
  19.  
  20. Okay, while you're at it, about the whole "smart-ass" thing, find a header
  21. I can include that will give me access to this mythical "getch()" function.
  22. It seems to be strangely lacking on this system.
  23.  
  24. >Also, the compiler the reader chooses is obviously going to make a difference
  25. >so I will remember to include which compiler I succesfully used with any
  26. >future code references to prevent the onslaught of nitpicking egoists from 
  27. >flooding my mailbox with things like "that won't work! Jeez you're dumb." 
  28.  
  29. Cool!  Now we can flood your mailbox with things like "that won't work
  30. for anyone else!  Jeez you're dumb".  If you want to post to a language
  31. newsgroup, kindly post answers in the language selected, *not* in the
  32. extended form of it your particular compiler happens to allow.
  33.  
  34. >To save the typing of those who wish to pick apart my friendly advice:
  35. >This code is not a tutorial in encryption or security, it is just meant to
  36. >show the original poster a way he can get input from the keyboard without
  37. >having it echoed to the screen! (I wrote it merely because I did not like
  38. >the limitiation of my compilers version of a function in conio.h called 
  39. >getpass() which limits the input to 8 characters. I also realize that the
  40. >buffer could overflow causing problems but on my computer using this function
  41. >I have input 300 characters without a problem- I haven't tried any more 
  42. >than that) 
  43.  
  44. I love it; I know the buffer could be overflowed, but it didn't matter
  45. when I tried it, so don't worry.  Clever.
  46.  
  47. getpass() is a nearly standard function (it's standard, it's just not
  48. standard *C*), and is actually a very good answer.  Passwords much over
  49. 8 characters may become insecure because it's easier to decrypt them
  50. in some cases.  :)
  51.  
  52. >/*-----------------------BEGIN CODE-----------------*/
  53.  
  54. >#include<stdio.h>
  55. >#include<conio.h>
  56.  
  57. Hmm.  My compiler doesn't have one of these.
  58.  
  59. >char *getstring_noecho()
  60. >{
  61. >  char *string;
  62. >  int i=0;
  63. >  _setcursortype(0);
  64.  
  65. Huh?
  66.  
  67. >  while(string[i-1]!=13) {
  68. >    string[i++]=getch();
  69.  
  70.  
  71. This is worse than it immediately appears:
  72.  
  73. string doesn't point anywhere yet.  You may overwrite random memory by
  74. doing this.
  75.  
  76. string[i-1] is invalid the first time through unless you have initialized
  77. string to point at least one char into a real object.
  78.  
  79. string[i-1] could be 13 by sheer chance, since it's uninitialized.
  80.  
  81. Do you have even a *fraction* of a clue what you're doing?
  82.  
  83. >  }
  84. >  string[i-1]=NULL;
  85.  
  86. Twit.  NULL may be (void *) 0, in which case, this won't work.  ASCII 0
  87. is *NOT* the same as NULL.  The first character in ASCII is called
  88. "NUL".  Count the L's.  (If you can't count to 2, write me privately,
  89. and I'll send you the numbers.)
  90.  
  91. >  return(string);
  92. >}
  93.  
  94. >void main()
  95.  
  96. Hmm.  What does "warning: return type of main is not `int'" mean?  Perhaps
  97. it means you're reading a book by Herbert Schildt.  If so, my apologies;
  98. you would have had no way of knowing you were being spoonfed lies.
  99.  
  100. >{
  101. >  char *password;
  102. >  printf("Enter password:");
  103. >  password=getstring_noecho();
  104. >  printf("%s",password);
  105. >}
  106.  
  107. >If you want to rag on this go ahead but remember that it was only meant as
  108. >a nice gesture to the person who had asked for a way to get input from the 
  109. >keyboard without having it echoed to the screen; I gave him a way. That
  110. >is the only thing this code is meant to do so for everyone who sits around
  111. >waiting to harp on someones code they dislike - get a life; if you don't
  112. >like someone's advice to someone else, give better advice or shut up!
  113.  
  114. Okay, I'll give better advice.  Don't post stupidly broken code.  You are
  115. not "helping" anyone by giving them bad advice.  (Unless they want homework
  116. done for them; false answers may help them learn to do their own work.)
  117.  
  118. Don't be "nice" if you can't actually contribute.  You seem to have this
  119. idea that a room full of idiots spouting nonsense, nicely, would be an
  120. improvement over a room with a few experts answering questions carefully
  121. and correctly, whether they were nice or not.
  122.  
  123. Tain't so.  I would personally be *pissed* if someone gave me example
  124. code, and it didn't work, more so if it was because the person obviously
  125. didn't have even the vaguest concept of how pointers work in C.
  126.  
  127. >Oh, and Tanmoy, don't pretend to have a clue when you don't.
  128.  
  129. *smirk*  This from someone who writes to uninitialized pointers?
  130.  
  131. >Fetelgeuse.
  132.  
  133. I'm leaving this in because I can't tell what it is.
  134.  
  135. -s
  136. -- 
  137. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  138. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  139. FUCK the communications decency act.  Goddamned government.  [literally.]
  140. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  141.